Check out

Is it possible to check

Re: Check the link connection
Mike.Scharnow - Thu Mar 05 08:44:01 EST 2015

What is Cust Req? What is Acpt Crit?

Are these DXL extension tools?

Are these module names?

Or link types?

Or attribute names?

Or project names?

Re: Check the link connection
sekrbo - Thu Mar 05 09:22:29 EST 2015

And what is link connection?

Re: Check the link connection
Mike.Scharnow - Fri Mar 06 02:58:10 EST 2015

So, to get a better overview, do I understand correctly?

You have an object attribute "Requirement Type" (or something like that) with the values "Customer Req" and Acceptance Crit".

Both, Requirements and Criteria are in the same module(?)

Is there a special link module used for creating the links between Reqs and Criteria, so that you can use the name of the link module for distinguishing e.g. links between Req and Crit and perhps links between Req and Test?

Or can you only use the object attributes as criteria?

Re: Check the link connection
Mike.Scharnow - Fri Mar 06 07:10:45 EST 2015

Good, so know we know information is available and how it is connected.

Finally, what do you mean by "check"? Which information do you need?

Let's assume that you do not want an overview on valid data (Traceability matrix) but a check whether any invalid data exists in a module.

In this case, the answer to your question is "yes, it is possible"  (sorry, couldn't resist).

I can think of the following cases to check, there might be more.

1. Cust req has one or more out links to Acpt Crit using the correct link module
2. Cust req has at least an out link to Acpt Crit where the wrong link module was used
3. Cust req has at least one out link to an object in the current module that is not an Acpt Crit
4. Cust req has no out link
5. Cust req has an in link
6. Acpt Crit has an out link
7. Acpt Crit has no in link
8. Acpt Crit has at least one in link from something that is not a Cust req
9. Objects exist that are neither Acpt Crit nor Cust req  (what about headings? what about object cells? what about deleted objects?)
10. Cust req has at least one out link to a different module than the current one

One might define that only the first case is valid and all other cases are invalid.

For most of the cases you should be able to write your own checks.

As an example for case 3, the following could be a basis for your checks:

Module m = current
Object oCustReq
print "Message Type; Case; Module; Source Object; Target Object; Message\n"
for oCustReq in entire m do {
 if isDeleted oCustReq then continue
 if table (oCustReq) or row (oCustReq) or cell(oCustReq) then continue
 if oCustReq."Type" "" != "Cust Req" then continue
 Link lOut
 for lOut in oCustReq -> "*" do {
  string sTarget = target lOut 
  if sTarget != name m then continue
  Object oTarget = target lOut
  if oTarget."Type" "" != "Acpt Crit" then {
   print "W;3;" (name m) ";" (oCustReq."Absolute Number" "") ";"(oTarget."Absolute Number" "") ";Target Type is " (oTarget."Type" "") ", but should be Acpt Crit\n"
  }
 }
}

You can copy the output and paste it into Excel (hence the ; as separator).

Hope this helps

*EDIT: Some typos / syntax corrections; added case 10 and refined case 3

Re: Check the link connection
Mike.Scharnow - Fri Mar 06 08:58:46 EST 2015

So, now we know the real question that you want to ask us. Great!

From this screenshot I would say, wrong links can be found by searching for

- Cust Req objects that have an out link

So, take the base code and if it reaches line 10, meaning as soon as you have found an out link for a Cust Req, print a warning message.

Re: Check the link connection
Mike.Scharnow - Mon Mar 09 04:36:48 EDT 2015

just to get this clear. The term

- for link in object -> "*"

will proceed all /out/ links of the object.

You get /in/ links with

- for link in object <- "*"

And for /in/ links, the "other side" is "source lIn", not "target lIn".

(for your info: for in links to work, all source modules have to be opened. you can see this in the doors client, where it says "link comes from 2:<unloaded>". Check for posts with the keywords LinkRef to see how to open the module. This is not important if all links that you look at are drawn inside a module)

Apart from the link direction and source vs. target, whether your code is correct, depends on what you specifically want to do. What it currently does is

- for every Cust Req in the module m

- - for every out (-> in) link of the CustReq to objects in module m

- - - give a message if the target (-> source) object is not an Acpt Crit.

So, when corrected, this code will detect links that go into a Cust Req and start from something that is not an Acpt Crit, so it would detect e.g. links from Cust Req to Cust Req.

Re: Check the link connection
Mike.Scharnow - Tue Mar 17 04:23:20 EDT 2015

That depends on your program. Do you see any specific code line where the problem occurs?

Are you still analyzing your in links? If so, it might be that you have too many modules open (every module that has an out link to your module).

Perhaps it is a good idea if you close all your open incoming modules after the processing of every 10.000?? in links?

Did you use Arrays that have grown too big?

Perhaps you can just tell your program to run in two steps, like one step up to chapter 5, the next steps chapter 6 and later.

@rest of the world: any general advice?

Re: Check the link connection
Mike.Scharnow - Tue Mar 17 05:12:22 EDT 2015

offset and len are out parameters.

Did you initialize them correctly? (int offset = 0, int len = 0) You should do this directly before you call findPlainText

Why do you use findPlainText at all? Is the attribute "Type" a free text attribute? if not, for single value attributes, a simple "if ot == a[I]" should be enough. If multiple values are allowed ("not set" & "Prod Req" at the same time), you can use  'if isMember (o."Type", a[I])'

Re: Check the link connection
Mike.Scharnow - Tue Mar 17 06:09:51 EDT 2015

- o."Type" is Object Text -> you mean that the attribute "Type" is of type "text" and not "enumeration", did I understand correctly? If so, I would consider this bad data model design, as every user might type the object type differently. And if you are really sure that the user only entered the values "not set", "prod req" and "test crit" then I do not see why 'if a[i] == ot' should produce a syntax error

- your lines "Object o = gotoObject..." must be removed. Your variable "o" already contains the object that you want to write to. There is the danger that your outer loop (for o in m) will not work correctly any more.

- I'm not really sure what the idea behind your "f_speicher" is. If I read the code correctly, you set a[I] to "" in some conditions. It might be that the next time you come to the line findPlainText... this command will not work as you tell it to find the empty string. Perhaps this is the stack overflow.

Re: Check the link connection
sa14 - Tue Mar 17 06:19:11 EDT 2015

Yes you understand it correctly the attribute "Type" is of type "text".

What you mean with "Object o = gotoObject..." must be removed ?

Re: Check the link connection
Mike.Scharnow - Tue Mar 17 07:42:24 EDT 2015

Wow, so then you should write additional scripts that check whether your colleagues entered any value which is not expected. Or you should persuade your DOORS DB Admins to think about a redesign. But that's not my business :)

gotoObject is almost never needed in a DXL script. It's only purpose is to set the focus to the described object, so that the user, when the script has finished, sees that object x is current now. Perhaps you wanted to use the function "object" (like in "Object oXY = object(123)"), but you also don't need that and should not use it here.

What you want is to set an attribute of a specific object. But the specific object in question is the one that your variable "o" already points to.

with your loop "for o in m", you tell DOORS: at the beginning, set o to the  first object. Then you make your test by looking at the attribute "Type" of this object. Finally you want to write to an attribute of the same object you just inspected -- but your variable "o" still points to this object.

What is also not so good: You have already defined a variable called "o". Now in the if-clause you define another variable called "o", which is only valid inside the if block (read http://de.wikipedia.org/wiki/Variable_(Programmierung)#G.C3.BCltigkeitsbereich_von_Variablen_.28Scope.29 for details). In the case that you really need to define another, new variable, use another variable name, in this case perhaps "oToBeChanged". But -- as I said, you don't need a new variable here.

Re: Check the link connection
Mike.Scharnow - Wed Mar 25 06:25:20 EDT 2015

Hi!

We had this before: "does not work" is not an error description where you can expect much help.

Create very simple and small dummy modules for testing.

If you don't have the DXL Debugger, then add print statements to several lines of your code.

Check, in which cases the code behaves as you expect it to do, and in which cases you expect a different behavior. Then you should eventually be able to spot the problem and solve your problems.

Regards,
Mike

Re: Check the link connection
adrianro - Wed Mar 25 06:30:46 EDT 2015

Leaving appart the dxl discussion, the easiest way to avoid this problems in the future is to force the link direction by a proper linkset strategy in the module configuration. This way you can avoid the user making mistakes with the link direction, as they can only use the outgoing links predemined by the administrator.

Regards

Re: Check the link connection
Mike.Scharnow - Wed Mar 25 06:53:17 EDT 2015

unfortunately they have a bad module design, Customer Requirements and Acceptance Criteria are within the same module, so the link direction cannot be enforced

:(

Re: Check the link connection
Mike.Scharnow - Wed Apr 08 10:06:33 EDT 2015

If your goal is to detect whether there is no in link then the following code might do what you want.

for oCustReq in entire m do {

 if isDeleted oCustReq then continue
 if table (oCustReq) or row (oCustReq) or cell(oCustReq) then continue

 LinkRef lrIn
 bool bHasAnInLink = false
 for lrIn in each (oCustReq) <- ("*") do {
     bHasAnInLink = true ; break
 }
 if (!bHasAnInLink) {
     oCustReq."Link-Scanner" ="missing in link from acpt crit" 
 }

Re: Check the link connection
Mike.Scharnow - Thu Apr 09 03:01:17 EDT 2015

Interesting. I copied this line directly out of the DXL help.

The word "each" means "Iterate through all incoming link references including those from baselines and soft-deleted modules." I guess that this functionality is not important for you.

So, remove the word "each" and it should work.

But: I just saw that I forgot your condition "Type" == "Cust Req".

So, insert a line

 if oCustReq."Type" "" != "Cust Req" then continue
 

directly after the line "if table (…"

Re: Check the link connection
Mike.Scharnow - Thu Apr 09 03:53:07 EDT 2015

I am not sure what you are trying to tell me or show me.

The screenshot that you included clearly shows that the object has an in link (yellow triangle with tip to the left). So, according to the requirements that you stated, it is correct that this object's Link-scanner attribute is empty.

Re: Check the link connection
Mike.Scharnow - Thu Apr 09 05:07:47 EDT 2015

Well, this is a different requirement. Compare this mail with the first sentence of your post from yesterday, 3:01 pm. See also my list from Mar 6 about different cases that you might need to check (in this list, I misunderstood the link direction that you need, so you have to switch CustReq and AcptCrit.)

Only when you are able to express exactly what you need, you will be able to find a solution for your problem.

So, I understand that the requirement for this check is "

1. For every object
2. in the module 'Requirements Specification'
3. whose attribute 'Type' is set to 'Cust Req',
4. its attribute 'Link-Scanner' shall be filled with the information 'missing in link from apct crit'
5. if there is
6. not at least one in link
7. from an object in the module 'Requirements Specification',
8. which has its attribute "Type' set to 'Acpt Crit'

"

Is this correct? Is this complete? (note that no "else/otherwise" is mentioned in this requirement.)

If you are satisfied with your requirement, it should be possible to follow this definition word by word / line by line and code it.

As to the solution: In the case that a) the requirement's part 8 is not so important, you are focused mainly on the part 7, and b) the link module used for links inside Requirements Specifications is different from the link module used for links from Feature Spec to Requirements Spec, then you are lucky.

In this case, you are only interested in the links going through the Requirements Specification intra module link module. Replace the "*" in the code with the name of the Requirements Specification intra module link module.

Re: Check the link connection
Mike.Scharnow - Thu Apr 09 08:34:44 EDT 2015

Most likely you will have a definition in your formal modules, which link modules are allowed for a specific target module (link restrictions).

Open your module, go to the properties of the module, go to the tab "Linksets", Look for the name of the link module (in the picture below, links from Pflichtenheft to Lastenheft must be drawn using the link module "Erfüllt",) (in the DXL command, use only the name "Erfüllt", not the full path "testb1/Erfüllt").

Then look into the module properties of the Feature Specification module, whether they use the same link module or a different link module.

Re: Check the link connection
Mike.Scharnow - Fri Apr 10 06:58:22 EDT 2015

So, as I said, if you are not interested so much in line 8 of the requirement that I formulated and if you are satisfied with the requirement otherwise, just replace the "*" in your current code with "AcptCrit_to_CustReq" and test whether you get the expected results.

Re: Check the link connection
Mike.Scharnow - Thu May 07 05:14:08 EDT 2015

I did not run the code, but from a first look, that looks OK. does it not work?

If so, add some print statements (like

print "Code point XX reached for object number " oProdReq."Absolute Number" "\n"

to see whether the code arrives at the lines you expect it to.

Re: Check the link connection
sa14 - Thu May 07 05:32:58 EDT 2015

It doesn´t work because I check the link connection with a existing link connection for example Prod Req and Cust Req.

And I want to check the Prod Req without a link connection, Prod Req stands allone.

These code doesn´t work too:

for oProdReq in entire m do {


 if isDeleted oProdReq  then continue
 if table (oProdReq) or row (oProdReq) or cell(oProdReq) then continue
 if oProdReq."Type" "" != "Prod Req" then continue

 LinkRef lrIn     
 bool bHasAnInLink = false  
                                
 if (!bHasAnInLink) {
     oProdReq."Link-Scanner" ="missing in link from Cust Req"  
     }
            
    
                }  

Do you know what I mean ?

Re: Check the link connection
GregM_dxler - Thu May 07 12:09:25 EDT 2015

Hi

In your post of 4:32 AM today, the code works perfect.  You set bHasAnInLink to false and then check if it is false.  Obviously it is false, regardless if there is a link or not.

In your previous post, in the code line 

for lrIn in oProdReq <- "ProdReq_to_CustReq" do { 

Note that the "ProdReq_to_CustReq" this is the link module you are using, but you need to put in the full path of the link module, especially if it is in a different folder.  I do a similar test and when I put in the full path, the code finds the in link.  If I only put in the link module name, it does not find the in link.

By the way, start a new thread when you have new questions.

Hope this helps,

Greg

Re: Check the link connection
Mike.Scharnow - Thu May 07 19:44:02 EDT 2015

One other idea: remember to create use cases and in each case you define what shall happen. Then see which of these cases work in your code and which do not. Then it will be much easier to test your code and to define what should work. This will lead you to the source code you will have to write.

I would say here you have the use cases

case 1: object is not a prod req

case 2: object is a prod req that has no in link at all

case 3: object is a prod req that has at least one in link from cust req (=through the link module prod_req_to_cust_req)

case 4: object is a prod req that has no in link from cust req but an in link through another link module

case 5: object is a prod req that has at least one in link from cust req and at least one in link through another link module

By the way: I still do not understand the difference between the situation you want to test again in your mail from 8 May and the situation you had on 8 April

And: there are some more situations in your link checker script which you want to test against (e.g. links from/to cust req). If all your tests are in one script, be sure that the result of one part of the script does not overwrite the results in the other part of the script.